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WEB BROWSER PLUG-IN INTERFACE SYSTEM 

FJELP OF THE INVENTION 
5 The present invention relates generally to computer networks, and more 

specifically to a system for integrating and unifying plug-in programs for web browsers. 

BACKGROUND OF THE INVENTION 

Web browser programs are used by network client computers to access content on 

10 the World Wide Web portion of the Internet. A web browser communicates over the 
Internet with web server computers using the Hypertext Transfer Protocol (HTTP). The 
web browser program allows a user to access web pages on different server computers 
through hypertext links to these pages. The web browser program then formats and 
displays these pages on the client computer. Early web browser programs only allowed 

15 the access and display of simple web pages comprising text or simple graphical content. 
Present web browser programs, however, are substantially more powerful and allow 
access to many different types of content, such as complex graphics, streaming audio, 
streaming video, and other types of content. Moreover, the advent of browser based 
programming languages, such as Java® and ActiveX^^, allow the incorporation of 

20 computer programs in web pages. This allows web pages to be dynamic and interactive, 
rather than simply a passive display application. 

The functionality of a web browser is extended thrpugh the use of "plug-in" 
programs. A plug-in program is a computer program that integrates with the web 
browser and extends the capabilities of web browser program in a specific way. For 

25 example, plug-in programs are available that provide the ability to play audio samples or 
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view video movies from within a web browser. There are presently himdreds of plug-in 
programs available for the two most popular web browsers, Netscape Navigator™ and 
Microsoft Internet Explorer"^^, and several dedicated web sites have been created just to 
list and allow downloading of popular plug-in programs. 
5 Plug-in programs allow a user to access a wide variety of browser enhancements 

by simply downloading the program and, in some cases, decompressing the program 
and/or running an installation script. Most current web browsers include facilities that 
manage and organize the various plug-in programs that a user has downloaded. 

With the increasing development of Intemet applications, different program 

10 formats and types of downloadable content are constantly being introduced. Application 
programmers must adapt to these changing programming formats to ensure that their 
plug-in programs are compatible with existing standards and protocols. One 
disadvantage of current web browser interface systems is that there is presently no 
mechanism to comprehensively manage custom applications. Instead, developers of the 

15 custom applications must tailor their plug-in applications to interface with the standards 
imposed by the web browsers. This limits the ability of developers to easily develop 
plug-in programs. 
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SUMMARY AND OBJEC TS OF THE INVENTION 

It is an object of embodiments of the present invention to provide a system that 
allows users to efficiently develop custom plug-in applications that share similar feature 
sets but have different user interfaces to allow access to and present the features. 
5 It is a further object of embodiments of the present invention to allow custom 

applications to be deployed either as stand-alone applications or as plug-in programs to 
one or more different types of web browser programs. 

A system for interfacing plug-in programs to a web browser is described. 
The web browser integration system comprises an application framework that is used to 
10 produce custom applications. Certain interfaces are defined that application components 
must implement in order to function within the interface framework. The web browser 
interface system contains a script engine that reads application scripts and automatically 
installs the components needed over the Internet. The interface system then plugs these 
components together according to instructions in the script and handles communication 
15 and interaction between them within the application. The plug-in integration framework 
is currently available as a plug-in program itself, or as a standalone application. 

Other objects, features, and advantages of the present invention will be apparent 
from the accompanying drawings and from the detailed description that follows below. 
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PRIEF DESCRIPTION OF THE DjflAWINOS 

The present invention is illustrated by way of example and not limitation in the 
figures of the accompanying drawings, in which like references indicates similar 
elements, and in which: 
5 Figure 1 illustrates a computer network system that implements one or more 

embodiments of the present invention; 

Figure 2 illustrates a functional block diagram of the plug-interface process within 
a web browser application environment, according to one embodiment of the present 
invention; and 

10 Figure 3 illustrates how the web browser program communicates with the plug-in 

interface host through either the web browser interface function, according to one 
embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A system for interfacing plug-in programs to a web browser is described. In the 
following description, for purposes of explanation, numerous specific details are set forth 
in order to provide a thorough understanding of the present invention. It will be evident, 
5 however, to one of ordinary skill in the art, that the present invention may be practiced 
without these specific details. In other instances, well-known structures and devices are 
shown in block diagram form to facilitate explanation. The description of preferred 
embodiments is not intended to limit the scope of the claims appended hereto. 
Hardware Overview 

10 Aspects of the present invention may be implemented on one or more computers 

executing software instructions. According to one embodiment of the present invention, 
server and client computer systems transmit and receive data over a computer network or 
standard telephone line. The steps of accessing, downloading, and manipulating the data, 
as well as other aspects of the present invention are implemented by central processing 

15 units (CPU) in the server and client computers executing sequences of instructions stored 
in a memory. The memory may be a random access memory (RAM), read-only memory 
(ROM), a persistent store, such as a mass storage device, or any combination of these 
devices. Execution of the sequences of instructions causes the CPU to perform steps 
according to embodiments of the present invention. 

20 The instructions may be loaded into the memory of the server or client computers 

from a storage device or from one or more other computer systems over a network 
connection. For example, a client computer may transmit a sequence of instructions to 
the server computer in response to a message transmitted to the client over a network by 
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the server. As the server receives the instructions over the network connection, it stores 
the instructions in memory. The server may store the instructions for later execution, or 
it may execute the instructions as they arrive over the netw^ork connection. In some 
cases, the downloaded instructions may be directly supported by the CPU. In other cases, 
5 the instructions may not be directly executable by the CPU, and may instead be executed 
by an interpreter that interprets the instructions. In other embodiments, hardwired 
circuitry may be used in place of, or in combination with, software instructions to 
implement the present invention. Thus, the present invention is not limited to any 
specific combination of hardware circuitry and software, nor to any particular source for 

10 the instructions executed by the server or client computers. 

Figure 1 illustrates a computer network system 100 that implements one or more 
embodiments of the present invention. In system 100, a network server computer 104 is 
coupled, directly or indirectly, over line 125 to one or more network client computers 102 
through a network 1 10. The network interface between server computer 104 and client 

15 computer 102 may also include one or more routers that serve to buffer and route the data 
transmitted between the server and client computers over line 121. Network 1 10 may be 
the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or any 
combination thereof 

In one embodiment of the present invention, the server computer 104 is a World- 

20 Wide Web (WWW) server that stores data in the form of 'web pages' and transmits these 
pages as Hypertext Markup Language (HTML) files over the Internet network 1 10 to the 
client computer 102. For this embodiment, the client computer 102 typically runs a "web 
browser" program 1 14 to access the web pages served by server computer 104 through a 
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web server process 116. In certain cases, web browser 1 14 can also be used to access 
data 108 served by other network servers, such as content provider 103. Examples of 
commercially available web browsers 1 14 that are executed by network client 102 
include Internet Explorer™ by Microsoft® Corporation of Redmond, Washington and 

5 Netscape Navigator™ by Netscape Communications® of Mountain View, California. 
In one embodiment of the present invention, client 102 executes a plug-in 
interface process 105 that represents an application framework that allows the 
development of custom applications and provides an interface through which native and 
non-native plug-in programs 127 can be managed and executed within the web browser 

10 program 1 14. The plug-in interface process 105 may represent one or more executable 
program modules that are stored within client computer 102 and executed by the client 
computer. Alternatively, however, it may be stored on a remote storage or processing 
device coupled to client 102 or network 1 10 and accessed by the client 102 to be locally 
executed. In a further alternative embodiment of the present invention, the plug-in 

15 interface process 105 may be implemented in a plurality of different program modules, 
each of which may be executed by two or more distributed server computers coupled to 
each other, or to network 1 10 separately. 

In one embodiment of the present invention, wherein network 1 10 is the Internet, 
network server 104 executes a web server process 1 16 to provide HTML documents, 

20 typically in the form of web pages, to client computers coupled to network 110. To 
access the HTML files provided by server 104, client computer 102 runs a web client 
process (typically a web browser, such as Netscape Navigator™ or Microsoft 
Explorer™) 114 that accesses web pages available on server 104 and other Internet server 
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sites, such as content provider 103 (which may also be a network server executing a web 
server process). It should be noted that a network system 100 that implements 
embodiments of the present invention may include a larger number of interconnected 
client and server computers than shown in Figure 1 . For this embodiment, the client 
5 computer 102 may access the Internet network 1 10 through an Internet Service Provider 
(ISP) 107. 

As can be appreciated by those of ordinary skill in the art, the representative 
networked computers of Figure 1, such as network server computer 104 can be 
implemented as any standard computer that includes a central processing unit (CPU) 

10 coupled through a bus to various other devices. These devices could include random 
access memory (RAM), a read only memory (ROM), and mass storage devices (e.g., a 
magnetic disk, optical compact disk, or tape drive for storing data and instructions). The 
computer also typically includes input/output devices, such as, a display device, 
keyboard, and network interface device, along with other similar devices or interfaces. 

15 Any of the computers in Figure 1 could be implemented in the form of personal 
computers, laptop computers, mainframe computers, or other type of workstation 
computers. The computers in Figure 1 could also be implemented in the form of portable 
or miniaturized computing devices, such as handheld personal digital assistants (PDA), 
including devices that communicate with other devices on the network over a wireless 

20 medium. In certain systems, the client computer can also be implemented as a dedicated 
Internet client, such as a television that includes Internet access. Such clients are typified 
by the WebTVrM system. 
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Web Browser Plug Interface Process 

In one embodiment, the web browser plug-in interface process 105 includes 
software components that are implemented to facilitate the creation and integration of 
various plug-in programs. The plug-in programs 127 may represent application programs 
5 that are written specifically for the plug-interface process ("native" plug-ins), and/or 
plug-in programs that are generic or not specifically written for the plug-in interface 
process ("non-native" plug-ins). The plug-in interface process 105 includes software 
components that allow non-native plug-ins to be adapted for use with the plug-in 
interface process. 

10 The plug-in interface process is part of an overall web browser application 

environment that can be used to produce custom applications for use within web browser 
1 14. The custom applications can be deployed either as standalone applications or web 
browser (e.g., Netscape Navigator or Internet Explorer) plug-ins. The plug-in interface 
process includes a script that describes several parameters of the custom application. The 

15 overall application environment consists of a set of plug-ins 127, an application script and 
the interface program available either as a standalone executable program, and/or as a 
web browser plug-in with an HTML page to define the application user interface. The 
plug-in interface process 105 is also able to install the custom application over the 
Intemet and update it at the binary level with small update files called "patches". 

20 The plug-in interface process 105 is divided into two parts. The first part is a 

single instance core, and the second part is a multiple instance plug-in host. The multiple 
instance plug-in host serves to host the plug-in programs and provide access to the 
features provided by the single instance core. The single instance core couples the plug- 
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in programs together according to parameters from an application script file and/or an 
HTML page and the execution context and hosting services. 

From the point of view of the web browser, all plug-ins accessible through a web 
page are the essentially same plug-in program. Parameters from the page then specify 
which particular plug-in the interface should host within the space reserved by the HTML 
code for the web page. In this manner, several different plug-in programs can be 
connected or interfaced with one another to form a uniform application with respect to 
the web browser. The plug-in interface allows plug-ins to be mixed with bitmaps and 
other display entities and spread around a web page while still functioning logically 
together. In this manner, customized user interfaces can be quickly developed. 

Figure 2 illustrates a functional block diagram of the plug-in interface process 105 
within a web browser application environment, according to one embodiment of the 
present invention. The web browser application 200 represents a model in which a set of 
plug-in programs and services are connected together in a web browser page. A running 
instance of the web browser application is associated with a particular context. More 
than one instance of an application can exist in a single process. As shown in Figure 2, 
the web browser application 200 includes two individual web pages 204 and 206. Each 
web page represents a separate context of a running instance of the web browser 
program. An instance of an application is associated with a particular context. Thus, in 
Figure 2, web page 204 and web page 206 each depict separate and imique contexts of 
the plug-in interface process. Although Figure 2 illustrates an example in which the 
plug-in interface process is implemented as part of a web browser process, it should be 
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noted that the plug-in interface process could also be implemented as a stand-alone 
program executed on the client computer. 

Each web page 204 and 206 include one or more plug-in programs. For example, 
web page 204 includes plug-in programs 212, 214, and 216. These can be native plug-ins 
that represent named objects. As such, they can receive parameters upon start up of the 
web page instance. A second type of plug-in is a hidden plug-in 208. This plug-in is not 
specified on a web page, but is created in a hidden window by core-installer 210 
according to a parameter specified by the web browser plug-in interface 202. The core- 
installer 210 is a special purpose plug-in that installs and patches applications and 
instantiations of the plug-ins as needed. 

The web browser plug-in interface 202 represents a single instance core of the 
interface process. The plug-in interface 202 includes one or more services, which are 
invisible static objects that communicate with the plug-ins for the web page contexts. 
The services do not receive parameters upon start-up. 

The web browser application 200 creates all controls on a web page in an 
arbitrary order. Once the control has been loaded it has the option of reading parameters 
from the page before it gets the actual handle of the window that has been reserved for it. 
When a web browser opens a page containing what appears to be multiple instances of 
the plug-in interface controls, it starts loading them one by one. 

When the web browser loads the first control, the single instance core of the plug- 
in interface 202 is created. Once the single instance core 202 has been created, all further 
creations of it will result in the same instance of the core, but not a new instance. This 
allows the plug-in interface to create a uniform application from muhiple plug-ms. 
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Each plug-in entity within the web browser application 200 includes a browser 
interface that allows communication with the web browser program. For the example of 
Figure 2, the web browser interface for each plug-in is labeled "NP and AX" These 
represent communication means to the web browser though either an ActiveX (AX) 

5 interface in the case of Microsoft Internet Explorer, or the Netscape Plug-in Application 
Programming Interface (NP) in the case of Netscape Navigator. 

Figure 3 illustrates how the web browser program communicates with the plug-in 
interface host through either the web browser interface function, according to one 
embodiment of the present invention. The plug-in interface host 306 acts as an interface 

10 between the browser and the plug-in 308 it is hosting. This enables a plug-in to function 
inside both types of browsers since they are not directly hosted by the browser, but rather 
inside an interface host that takes care of translating calls from the browser to the plug-in 
interface. Various web-page parameters 302 are passed to the plug-in 308 through the 
plug-in interface 306. 

15 The plug-in host is created once the single instance core 202 has been created. As 

illustrated in Figure 3, the plug-in host reads three key parameters from the web page, 
these are labeled, "Name'*, "ClassID", "Connect". These parameters instruct the plug- 
interface process what control to put in the space reserved for a plug-in program. 

Once the plug-in interface process has read the ClassID parameter, it requests the 

20 core-installer plug-in 210 to create an instance of a native plug-in (e.g., plug-in 212) with 
a plug-in Type ID equal to the ClassID. When the instance has been created, all other 
parameters are passed from the web page to the plug-in instance just created for reading. 
The plug-in interface process then looks at the Name and Connect parameters. The 
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Connect parameter (optional) contains one or more names of other plug-ins that this 
particular plug-in wishes to connect to. The plug-in host sends all connection requests to 
the single instance core. The single instance core builds a list of connection requests for 
each plug-in. It then monitors all plug-in creations by the Opium hosts and delegates the 
connection when plug-ins that have an outstanding connection request are created. All 
connections are made according to context. Thus, for example, if plug-in 214 wishes to 
connect to plug-in 216, it can only receive a connection to plug-in 216 within the same 
execution context. That is, the same execution context in a web page (e.g., web page 
204) of the web browser. No connections between execution contexts are allowed. 

During actual start-up and implementation of a plug-in interface process, 
particular complexities may be encountered regarding how to locate plug-ins on the client 
computer and creating an instance of them, installing them if they can not be found or 
upgrading them if they are outdated. All of these complexities are handled by core- 
installer special purpose plug-in. The core-installer plug-in resides in the same binary file 
as the plug-in interface process. This is ensures the availability of the core-installer plug- 
in. Each plug-in interface application must include the core-installer attributed according 
to its needs, thus, as shown in Figure 2, each web page 204 and 206 includes a core- 
installer plug-in. For a web page, this is done by placing the core-installer on the web 
page and giving it parameters specifying the application attributes. For a stand-alone 
application, this is done by containing it and attributing it in the standalone executable. 
The core-installer parameters that define an application are: Script, AppName, Version 
and View. AppName is the name of the application. The core-installer looks for a key 
by this name under a registry to find the location of the application content. The script 
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parameter specifies the URL (Uniform Resource Locator) to the application script. The 
version parameters specifies the lowest version of the AppName application needed to 
load the application. The View parameter specifies the name of a view section in the 
application script that defines what hidden plug-ins should be created by the core- 
installer. Hidden plug-ins have the access to the same features as visible plug-ins. The 
difference is that they are hosted by the core-installer in a hidden window instead of 
being hosted by a regular plug-in host. 

The use of parameters transmitted from a web page to the plug-in interface allows 
for the automatic installation of plug-in and content according to instructions from an 
application script. This also allows the automatic upgrade of previously installed plug- 
ins and content as new versions become available. In one embodiment, plug-ins can be 
"torn" from a web page, by moving the plug-in from its embedded location on the web 
page to a separate window that can be moved around and resized. The plug-in interface 
process can also incorporate a file manager service that allows plug-ins to load 
application content with out having to know the physical location on the client computer. 
In addition, the interface process can include a persistent property manager that allows 
plug-ins to persist in a particular state in key-value pairs. The data can either be persisted 
on the client computer or on a separate persistence server. 
Exempt? Plwg-In Appligatiipn 

The following description provides an example of how a simple application is 
built using the plug-in interface, according to one embodiment of the present invention. 
For this example, the application is a small chat application consisting of five separate 
plug-in programs, a logic plug-in, an input field, an output field, a user list plug-in, and a 
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sound engine plug-in. The application also uses four small soimd files that are played on 
certain events in the chat application. To play these files, the chat application uses the 
sound engine plug-in. The application is deployed in a web browser so an HTML page is 
also provided. 

The output field plug-in is a generic list control plug-in that accepts three 
parameters, direction, font, and color. The direction parameter specifies whether new 
lines to the history should be added from the bottom or the top. The font parameter 
specifies in what font lines in the history list should be rendered, and the color parameter 
specifies the color of the lists box background. 

The input field plug is a generic input control that accepts two parameters, font 
and color. The font parameter specifies the font in which the input should be rendered, 
and the color parameter specifies the color of the input box background. 

The logic plug-in contains the actual logic for the chat application. It handles 
server connection and the organization of users into chat groups. The logic plug-in 
accepts 3 parameters, login, password, and server. The login parameter is a string 
specifying the user's login ID. The password login is a string specifying the user's 
password, and server specifies the name of the server to coimect to. 

The user list plug-in displays a list of all the users that are currently chatting. This 
plug-in accepts no parameters. 

The sound engine is a plug-in capable of playing sound files, it also takes care of 
mixing the different play requests that the plug-ins that connect to it make. The sound 
engine up-samples or down-samples the play requests when needed. This plug-in accepts 
three parameters, SamplesPerSec, channels, and BitsPerSecond. The SamplesPerSec 
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parameter specifies the bit rate at which the sound should be played. The channels 
parameter selects between mono or stereo mode, and the BitsPerSecond parameter 
specifies 8-bit or 16-bit resolution. 

After the plug-ins and their associated parameters have been defined, an 
information file is compiled. The information file contains several sections in a file 
format denoted by a SectionName. Pseudo-Code for an information file for the example 
chat application is provided in Appendix A of this specification. 

Once the information file is defined and processed, the HTML page for the 
application is defined. For the exemplary chat application, the user interface consists of 
two web pages. The first web page comprises a page that allows a user to enters his login 
and password. The second web page provides a page in which the user inputs and sees 
the chat session in progress. In one embodiment, because the login page needs to send 
parameters to the chat page, Microsoft Active Server pages are used to read the HTTP 
headers. However, this example could easily be converted to use regular CGI or some 
other web application model. 

Microsoft Active Server Pages also provide the option of saving the redundancy 
of writing the plug-in definitions for both browser many times. Sample software pseudo- 
code that works in both Netscape and Microsoft browsers to insert a plug-in to a web 
page, according to one embodiment of the present invention, is provided as below. It 
should be noted that throughout the example pseudo code provided for the chat 
application, the generic web browser plug-in interface program may be referred to as 
"OPIUM", with appropriate labels associated therewith. 

<object 

id = "OPIUM" 
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classid = «CLS1D:00000004.C001-FOOD-BABE-OOOBADCOFFEE' 

codebase = **http://www.oz.corn/Opium/install/opiurn.cab" 

width = 2 

height = 1 > 



5 <param name = "OPIUM_Name" value = "OPIUMServices"> 

<param name = "OPIUM_ClassId" value = " {e05923b0-9cb8- 1 1 dl-a58c- 
00a0c91e530e}'> 

<param name = "Script" value = 
"http://www.oz.eom/install/chat/b 1 2/Chat.ozi"> 
1 0 <param name = " Appname" value = "Chaf 

<param name = "Version" value ~ "I2'*> 

<param name = "View" value = "Chat.view"> 

<param name = "Logic.Login" value = "Hilmar"> 

<param name = "Logic.Password" value = "1234"> 
15 <embed 

type = "x-world/ozworld-4" 

width = 2 

height = 1 

align = "left" 

20 OPIUM_Name = "OPIUMServices" 

OPIUM^Classld = "{e05923bO-9cb8-l Idl-a58c-00a0c91e530e}" 

Script = "http://www.oz.com/install/chat/bl2/Chat.ozi" 

Appname = "Chat" 

Version ="12" 
25 View = "Chat, view" 

"LogicLogin" = "Hilmar" 

"Logic.Password" -"1234" 

pluginpage = "http://www.oz.com.Opium"> 

</embed> 
30 </object> 



For the above example, some code is different between plug-ins and it needs to be 
entered twice for each plug-in. To eliminate this redundancy two ASP functions are used 
35 that can be included on a ASP page and used to embed controls. These are the functions 
AddParam and InsertControl AddParam adds parameters to a global array called 
OPIUM_j)arams. InsertControl adds a control to a page and gives it the parameters from 
the param array and clears the param array. 



40 <% 

Redim OPIUM_params (2,0) 
Sub AddParam (name, value) 

top = unbound (OPIUM_params, 2) 
ReDim preserve OPIUM jarams (2, top+1) 
45 OPIUM_params (0, top) = name 

OPIUMjwams (1, top) = value 

End Sub 
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Sub InsertControl (name, guid, width, height) 
code = VbCrLf 

code = code & "<object " & VbCrLf 
code = code & " id = ""OPIUM"" " & VbCrLf 
5 code code & " classid = ""CLSID:00000004-C00 1 -FOOD-B ABE-OOOB ADCOFFEE"" " & 

VbCrLf 

code = code & " codebase = " " " & 
"http://www.oz.com/Opium/install/opiuni.cab" & " " " " & VbCrLf 
code = code &" width = "& width & VbCrLf 
1 0 code = code & " height = " & height & " > " & VbCrLf 

code =^ code & " <param name = " "OPlUM_Name" " value = " " " & name & " " & 

VbCrLf 

code = code & " <parara name = " "OPIUM^ClassId" " value = " " " & guid & " " '*>" & 

VbCrLf 

15 ArrayLimit = Ubound (OPIUM jarams, 2) - 1 

For I = 0 to ArrayLimit 

code = code & " <param name = " " " & OPIUM jparams (0, 1) & " " " value = " " " & 
OPIUM jparams (!,!)& >" & VbCrLf 
Next 

20 code = code &" <embed" & VbCrLf 

code = code & " type - " " x-world/o2world-4" " " & VbCrLf 

code = code & " width = " & width & VbCrLf 

code = code & " height = " & height &n VbCrLf 

code = code align =""lefl"" "& VbCrLf 

25 code ^ code & " OPIUM_Name = " " " & name & " " " " & VbCrLf 

code = code & " OPIUM_CIassId = & guid & " " " " & VbCrLf 

For I = 0 to ArrayLimit 

code = code & " " & OPIUM jarams (0, 1) & " " " & 
OPIUM j>arams (1, 1) & " " " " & VbCrLf 
30 Next 

code = code & " pluginpage = " & "http://www.ozxom/Opium" 
&" >"& VbCrLf 

code = code &" </embed>" & VbCrLf 
code = code & "</object>" & VbCrLf 
35 Response.Write code 

Redim OPIUM jarams (2,0) 

End Sub 

%> 

40 By using this technique the HTML code above is reduced to the following ASP 

code: 



<% 

AddParam "Script", "http://www.02.com/install/chat/bl2/Chat.02i" 

45 AddParam "Appname", "Chat" 

AddParam "Version", "12" 

AddParam "View", "Chat. view" 

AddParam "LogicLogin", "Hilmar" 

AddParam "Logic.Password", "1234" 
50 InsertControl "OPIUMServices", "{e05923b0-9cb8-I Idl-a58c.00a0c91e530e} " , 2, 1 

%> 
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The Login.html only contains one HTML form, as exemplified by the following 
pseudo-code: 



<fonn method= "post" action = *'chat.asp"> 
5 <p> 

Login<br> 

<input type= "text" name= "login" maxlength="15" size="15"> 

</p> 
<p> 

10 Password: <br> 

<input type="password" naine="password" maxlength="15" si2e="15"> 

</p> 
<p> 

<input type="submil" name="submit" value="Submit"> 

15 </p> 
</fonn> 



The Chat.asp is the page where the user engages in the actual chat. Chat.asp reads 
parameters from the HTTP POST header from login.html and gives the controls 
20 parameters according to that. Pseudo-code for the chat example is provided below. Note 
that the code below specifies a page that does not include any aesthetics elements 
common to HTML programming. 



<html> 
25 <head> 

<title>Chat</title> 

</head> 

<body> 

<% 

30 <% 

AddParam "Script", "http://www.o2.coni/Opium/install/chat/bl2/Chatozi" 
AddParam "Appname", "Chat" 
AddParam "Version", "12" 
AddParam "View", "Chatview" 
35 AddParam "Logic.Login", Request.Form ("Login") 

AddParam "LogicPassword", Request.Form ("Password") 

InsertControl "OPIUMServices" , "{e5923b0-9cb8-lldl-a58c-00a0c91e530e}" , 2, 1 

%> 
< ! 

40 This asp code inserts the Corelnstaller plug-in. As you can see the plug-in is not called Corelnstaller but 
OPIUMServices. This is done to give the idea that there is nothing magic about the names of the instance. 
The instance name is used when reporting events from this plug-in to the user. All connections are also 
done on the instance name. It is the GUID that gives the type of an Opium plug-in. 
Parameters for the Corelnstaller: 
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"Script" here we give the location of the application script file that we are going to use. We have put our 
script file, called Chat.asp in the /Opiuni/install/chat/bl2 directory of the www.02.com server. We give the 
Corelnstaller plug-in this information with the "Script^parameter. 

"Appname" tells the Corelnstaller plug-in that all plug-ins we want belong to an application named Chat, 
"version" tells the Corelnstaller plug-in that the version of the application should be equal or greater than 
12. 

"view" tells the Corelnstaller plug-in that it should create all the hidden plug-ins in section Chat.view (that 
is where our logic plug-in and Sound Engine plug-in are listed). 

Two parameters for hidden plug-ins are overridden here over the parameters ft-om the application script. 
This is done by naming the hidden plug-in plus a \' and then the parameter to override. Here we have 
overridden the "Login" and "Password" parameters for the logic object but keep the "Server" parameter as 
it is in the script. 



<tabie border=l> 
<tr> 

<td> 

<% 

AddParam "Opium^Conncct", "Logic" 

InsertControl "UserList" , "{0DC81 120-766A-618D-D000-00104BC64B92} ", 

%> 
< ! . . 

Here we insert the userlist plug-in. We connect it to the hidden logic 

plug-in created by the Corelnstaller, so the userlist can affect the state of the logic. The 
userlist plug-in accepts no other parameters. 
- -> 



100, 200 



</td> 
<td> 



<table> 



<tr> 



00104BC64B92}",250, 180 



<td> 

<% 

AddParam "Direction", "bottom" 
AddParam "Font", "Helvetica, 14, 400,2" 
AddParam "Color" , "16777215" 

InsertControl "OutPut" , "{302CD780-B6E7-AA9A-F86D- 

%> 
< ! 

We don't need to connect the OutPut plug-in to 
anything, the logic plugin connects to it from the apphcation script file. 
We just have to make sure that the name here is the same as the one the 
logic plug-in is trying to connect to from the OZi file. The plug-in 
specific parameters tell the output plug-in to have chat history to flow 
bottom up, type of the font and the background color. 

- -> 

</td> 



</tr> 
<tr> 



<td> 



00104BC64B92}", 250, 20 



<% 

AddParam "Opium^Connect", "Logic" 

AddParam "Font", "Helvetica, 14, 400, 2" 

AddParam "Color", "16777215" 

InsertControl "Input", "{53F29A30-B6E7-AA9A-F86D- 
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%> 
< ! - - 

Here we connect the input plug-in to the logic so it 
can transmit text to the conference. The plug-in specific parameters tell 
5 the output plug-in the type of the font and the background color. 

--> 

<Jtd> 

</tr> 

</table> 

10 </td> 
</tr> 

</table> 

</body> 
</html> 

15 

The next step is deployment. To deploy the chat apphcation, three cabinets are 
created. These cabinets are as follows: chat.cab, stdplugs.cab and sound.cab. These are 
put in the information file, Chat.ozi. 

If there will be an updated version, a patch is created, and then the version 
20 number of the web page is incremented. When the core-installer plug-in is initialized, it 
sees that the web page needs a newer version of the application than is currently installed 
and will try to download a patch and apply it. 

A user wanting to use the chat application will open the login.html in the web 
browser. There he will enter his login and password and submit the form which gets 
25 posted to chat.asp. The asp engine executes the scripts specified in chat.asp and servers 
the HTML to the browser. 

The browser parses the HTML given to it and for each reference embedding it, 
gives it the parameters. The object is always the same object, because of the single 
instance shared logic, and it builds up a list of all the plug-ins that are needed. When the 
30 plug-in interface process is requested to create the core-installer plug-in, it creates and 
gives it the list of the plug-ins that need to be created. Once the core-installer plug-in is 
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created it stops adding to the list of plug-ins to create and just forwards them to the core- 
installer as the requests are made. 

When the core-installer plug-in is created, it reads in the AppName, Script, 
Version and View. It starts by checking ifthe application by the name. IftheAppName 
is found, the core-installer searches for the FileRoot string value under that key and reads 
the path entered there. If all these checks are passed, the core-installer plug-in is ready to 
create all the plug-ins 

In the foregoing, a system has been described for interfacing plug-in programs to 
a web browser. Although the present invention has been described with reference to 
specific exemplary embodiments, it will be evident that various modifications and 
changes may be made to these embodiments without departing from the broader spirit 
and scope of the invention as set forth in the claims. Accordingly, the specification and 
drawings are to be regarded in an illustrative rather than a restrictive sense. 
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[Application] 
name = ''Chat" 

displayname = ''Opium Chat" 
version = 12 

views = chat. view 

The application section contains information about the 
application. 

"name" is the name of the application, the 
Corelnstaller plug- in 
matches 

this name with the parameter from the web page and if 
a match occurs 
then 

it uses this script as an application script. 

"displayname" This string is the human readable name 
of the application, it is displayed on all dialogs and 
messages that come from Opium. The string Opium never 
comes before the eyes of the user. 

"version" is the application version. The 
Corelnstaller plug- in matches the parameter from the web 
25 page with this one. If the 
parameter 

on the web page is the same or lower the Corelnstaller 
plug- in knows 
that 

30 the application is up to date and it is safe to start 

creating plug- 
ins. 

If the version number given on the web page is higher 
a patch or a 
35 fresh 

install is needed. As we see here this is version 12 
of our chat 

application. 

40 "views" usually contains a list of fields that each 

specifies a name of a 

view section. In our case there is only one view 
available. 



10 



15 



45 This is the view section specified above in the 

application section. It specifies what hidden plug- 
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ins and services should be available in this 
particular view, 

'"hidden" contains a list of fields that each specify a 
name of a section that defines attributes of the 
hidden plug- in. In our case we have two hidden plug- 
ins, the chat logic plug- in and the SoundEngine plug- 
in. 

''services" contains a list of services that should be 
available to applications displaying this view of the 
application. In our case we only have one service, 
the FileManager that we need to allow plug-ins to 
locate the content (the sound files) on the users 
computer. 



This is one of our hidden plug-in, the chat logic. 
Here all of its parameters are specified in the 
application script, this is unusual, normally 
parameters that are session oriented, like login and 
password come from the web page. These parameters are 
put here to show how parameters in the script are over 
ridded on the web page. Having these parameters here 
also gives the option of creating a simple web page 
allowing users to enter chat sessions on the default 
server "chat.oz.com" with out having to create a form 
for them to login. In that case all the user would 
bear the same name, ''incognito", 

"OPIUM_ClassId" the type identifier for the plug-in. 
It can not be overridden from the web page. 

"OPIUM_Name" a human readable name for this particular 
instance of the OPIUM_ClassId plug- in. This name is 
for example used when connecting plug -ins together. 

"OPIUM_Connect" can be overridden from the web page. 
Specifies a list of fields that each name a plug-in 
that this plug- in wishes to receive a pointer to, when 
each plug- in is created the single instance part of 
OPIUM checks if there is any plug- in that has asked 
for a connection 

this newly created plug- in. If so the plug- in that 
asked for the connection will get a call to its 
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Connect function of lOZPlugin interface with an 
lUnknown pointer to the newly created plug- in. Then 

the ; plug- in wanting the connection usually queries the 

lUnknown pointer 

for an 

interface it knows how to communicate with. 

Our logic object wants a pointer to the OutPut, the 
UserList and the SoundEngine so it can update these 
plug- ins as events in the 
conference 

occur. The logic plug- in does not connect to the 
input plug- in. The 

input 

connects to the logic because events flow from the 
input and to the logic not the other way around. 
Because of this it is simpler to 

have 

the input getting a pointer to the logic and query for 
a lAcceptText interface to feed text input to the 
logiv. In the case of the output 

and 

the userlist, it is simpler to have to logic receiving 
pointers to the plug- ins instead of vice versa 
{actually the userlist also connects to the logic 
because users can affect the sate of the logic through 
the userlist) . 

''Login" a plug- in specific a parameter, can be 
overridden from the web page. 

''Password" a plug- in specific a parameter, can be 
overridden from the we page. 

"Server" a plug- in specific a parameter, can be overridden 
from the web page. 



This is the second one of our hidden plug-ins. It has 
the same OPIUM specific parameters as the logic above, 
with the exception of OPIUM^Connect which is missing 
because the Sound Engine is not 
connecting 

to any plug- in. The SoundEngine also has the plug- in 
specific parameters: SamplesPerSec, Channels and 
BitsPerSecond, explained above. 
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[ S our c e S e rve rNarae s ] 

http : //vww. oz . com/Opium/ install/Chat/bl2 

This section contains a list of lines that each 
defines an URL where the installation image can be 
found. If the Corelnstaller plug-in needs to do an 
install before, plug-ins can be created, it 

loops 

through all of the lines until it finds the cabinet it 
is looking for. In our case, there is only one URL so 
if the installation image can not 

be 

found there the installation will fail. 
tPatchFiles] 

http : //www . 02 . com/ Opium/ install/Chat/patches/12tol3 . rtp 

This section contains a list of lines that each 
defines an URL to a patch file. If the Corelnstaller 
plug- in needs to do an 
upgrade 

to the application before it can start creating plug- 
ins it uses these URL to find a patch file to update 
the application. In our case we 

have ; only one possible patch file location, if the patch 

is not found 

there 

the only resort is a complete install from the 
locations specified in 

the 

[SourceSereverNames] section. 



Defaultlnstall is an install section. Install 
sections contain information about the nature of an 
installation. An application script can specify many 
install section that each have different instructions 
in the. The install sections are referred to by a 
parameter to the Corelnstaller. The Name 
Defaultlnstall is a special one because that does not 
need to be referred to from the web page. If no 
section is specified, Defaultlnstall is used. 

"RequiredDiskSpace" defines the amount of free disk 
space the drive that the users selects to install to, 
needs to contain to make the installation. This is 
the work space the installation needs, not necessarily 
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the amount the application will take after the 
installation is complete. That is usually lower than 
the work space needed as cabinets can be deleted after 
they have been extracted. 

5 

*'CopyFiles" contains a list of fields that each is a 
name of a copy- file- section. The Corelnstaller plug- 
in downloads and installs 

all 

10 the sections that are listed here. In our case we ask 

that two copy-file-sections be installed, Chat.app and 
Chat . content . 

'"AddReg" contains a list of field that each is a name 
15 of an add- reg- section. The Corelnstaller plug- in will 

add all lines 
specified 

in the add-reg-sections to the registry. In the case 
of our Chat application, we ask that only the Chat. reg 
20 section be added to the registry. 



Chat.app is a copy- file- section as we see in the 
Def aultlnstall section above. Copy-file-sections 
25 contain a list of lines that each 



have 



30 the 



two fields, the name of the cabinet and its estimated 
size. The Corelnstaller plug-in tries to download 
each cabinet from any of 



URLs from the SourceServerNames section. When all the 
cabinets have been downloaded, the Corelnstaller plug- 
in extracts them to the 
locations ; specified by the DestinationDirs section. 

35 

This copy-file-section lists two cabinets to install. 



40 



^'chat.cab" here we put CLogic.dll file that contains 
the logic plug- in and the user list plug- in. 

''StdPlugs .cab" here we put stdplugs.dll that contains, 
among others, the input plug- in and the output plug- 
in. We also put the SndEng.dll in this cabinet. 

45 Actually we could just have one cabinet here and put 

both dlls into that cabinet. We put our dlls in 
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different cabinets to better show possibilities of a 
copy file section. 



This is another copy- file -section, it contains only 
one cabinet, the sound cabinet that contains the 
sounds that the chat application will play on several 
occasions . 



Chat.reg is an add-reg-section as we see it is 
referred to by the Def aultlnstall section above. Add- 
reg-sections contain a list of 

lines 

that the Corelnstaller plug- in should add to the 
registry. Each line 

in 

the list consist of 5 fields, they are: 

0. specifies under what root key the entry should be 
added, possible values are: ^^HKCR", ^^HKCU" , ^^HKLM" and 
HKU. 

1. specifies the sub key where the entry should be 
added. Escape sequences are need to for backslashes, 
because values with white spaces in them are not 
possible in the OZi script format unless they 

are 

string (values inside . Strings in the OZi file 

format follow the same files a C strings, 

2. the value to be created under the subkey. 

3. the type of the data that follows, possible 
values are: ''REG^SZ" and ''REG_DWORD" . 

4. the data to enter. 

Our chat application enters nothing to the registry. 
The line above is a comment and is only kept here as 
an example of how the Corelnstaller plug- in can be 
made to update the registry. 

The DestinationDirs section contains information about 
the 
destination 
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that each cabinet in a copy-file-section should be 
extracted to. It consists of a list of lines that 
bear the name of their respective copy-file-sections. 
The first field in each line is a number, each number 
has a special meaning to the Corelnstaller plug- in: 
1 is the application directory as selected by 

the user. 

10 is the windows directory on the computer. 

11 is the windows system directory on the 

computer . 

The second field contains a relative path under the 
destination 
directory. 

In both the copy- file-sections in our chat application 
are to be extracted to the user selected application 
directory. In addition to 

that 

we say that all cabinets in the Chat. content section 
should go in a 
subdirectory. 

sound under the user selected directory. We could 
have also done this 

by 

specifying relative information in the sound. cab 
cabinet but this 
gives a 

better idea of the capabilities of the Corelnstaller 
plug- in. 
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1 . A method of interfacing plug-in programs within a web page, comprising the 
steps of: 

identifying one or more plug-in programs to be executed within the web page; 
defining a script format defining a plurality of parameters included within each 
plug-in program; 

providing a plug-in interface program that unifies the plurality of parameters for 
each plug-in program, resolves dependencies among the one or more plug-in programs, 
and establishes the display and execution of each plug-in program within the web page. 

2. The method of claim 1 wherein the web page is displayed on a client computer 
through a web browser application locally executed on the client computer; 

3. The method of claim 2 wherein the web browser program comprises one of 
Netscape Navigator and Internet Explorer, and wherein each plug-in program includes an 
interface allowing the plurality of parameters for each plug-in program to be passed to the 
web browser program. 

4. The method of claim 3 wherein the plurality of parameters comprises a plug-in 
name, a plug-in identifier, and a plug-in connect parameter. 
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5. The method of claim 4 wherein the plug-in connect parameter defines a name of 
one or more plug-in programs that a first plug-in program will connect to. 



6. The method of claim 4 wherein a subset of the one or more plug-in programs are 
native plug-in programs written for the plug-in interface program. 

7. A client computer coupled to a server computer over a network, the client 
computer comprising: 

a web browser process accessing World Wide Web content in Hypertext Markup 
Language fomiat firom a web server process executed on the server computer; 

one or more plug-in processes executed in conjunction with the web browser 
process and operable to display content within a web page displayed on the client 
computer; 

a plug-in interface process executed in conjunction with the web browser process 
and configured to define a common set of functional set of parameters and application 
program interface structures for each of the one or more plug-in processes. 

8. The client computer of claim 7 wherein the plug-in interface process further 
comprises a core installer process that functionally couples the one or more plug-in 
programs together in accordance to the functional set of parameters. 
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9. The client computer of claim 8 wherein the core installer accesses a script process 
that specifies a network address of a script program that defines the functional set of 
parameters. 



10. The client computer of claim 9 wherein the client interface process comprises one 
of a single instance core and a multiple instance plug-in core. 

1 1 . The client computer of claim 1 0 wherein the one or more plug-in programs 
include hidden plug-ins that are created in a hidden window by the plug-in interface 
process and are not specified on the web page. 

12. The client computer of claim 10 wherein the one or more plug-in programs 
include native plug-ins that represent named objects that are specified on the web page. 

13. The client computer of claim 9 wherein the web browser program comprises one 
of Netscape Navigator and Internet Explorer, and wherein each plug-in program of the 
one or more plug-in programs includes an interface allowing the plurality of parameters 
for each plug-in program to be passed to the web browser program. 

14. A distributed computw network system comprising 

a server computer executing a web server process providing World Wide Web 
content in Hypertext Markup Language format to one or more client computers coupled 
to the network system; and 



32 



wo 01/39046 PCT/USOO/32171 

a client computer executing a web browser process accessing web pages provided 
by the server computer, the client computer further including one or more plug-in 
processes executed in conjunction with the web browser process and operable to display 
content within a web page displayed on the client computer, and a plug-in interface 
5 process executed in conjunction with the web browser process and configured to define a 
common set of functional set of parameters and application program interface structures 
for each of the one or more plug-in processes. 

15. The distributed computer network system of claim 14 wherein the plug-in 

10 interface process further comprises a core installer process that functionally couples the 
one or more plug-in programs together in accordance to the functional set of parameters. 

16. The distributed computer network system of claim 15 wherein the core installer 
accesses a script process that specifies a network address of a script program that defines 

1 5 the functional set of parameters. 

1 7. The distributed computer network system of claim 1 6 wherein the one or more 
plug-in programs include hidden plug-ins that are created in a hidden window by the 
plug-in interface process and are not specified on the web page, and native plug-ins that 

20 represent named objects that are specified on the web page. 

1 8. The distributed computer network system of claim 1 7 wherein the web browser 
program comprises one of Netscape Navigator and Intemet Explorer, and wherein each 
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plug-in program of the one or more plug-in programs includes an interface allowing the 
plurality of parameters for each plug-in program to be passed to the web browser 
program. 
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